@BenHenning this is a quite old draft, do you plan on updating this to be able to get it merged before the user testing deadline?

@BenHenning this is a quite old draft, do you plan on updating this to be able to get it merged before the user testing deadline?

For posterity we're trying to figure out whether this is an actual blocker for January testing, though it would be nice to find a solution.

To that end I have investigated this more and found that it's very much still an issue. I was wondering a bit whether #9245 might affect this because it changed a bit with auto hiding behavior, but the alert dialog situation is still very much broken.

Fundamentally what's happening here is that the browser seems to send a focusout event asynchronously after execution resumes when the dialog is closed. This produces a rather tricky situation because it's not clear how long (or if to ever) to ignore signals of lost focus after the dialog closes. From discussion in the team meeting this week, one option was to replace alert() and other system dialogs with a custom implementation (like we use for toast now) since that could be advantageous long-term and adds some UI and accessibility consistency. This leads to two overall solutions with separate problems:

1. Introduce custom modals for alert(), prompt(), and confirm().

• This will require central DOM management unlike toasts because there's no way to get the workspace without breaking the existing API (otherwise this is a breaking v13 change).
• Input needs to somehow be blocked for both mouse and keyboard users while the new dialogs are open. This requires a combination of a full-screen translucent overlay that blocks mouse inputs with manually disabling key inputs.
• There are some questions about to best style these, but this isn't particularly difficult to address.

3. Build a mechanism that attempts to robustly ignore the focusout event that triggers when the system dialog closes.

• A likely approach would be to introduce some sort of release latch mechanism that essentially disables interpreting focusout events until after receiving exactly the first one after a dialog closes (taking into account that explicit focus changes may also trigger a focusout).
• One fundamental problem is it isn't guaranteed that all browsers will have the same focus issues for system dialogs.
• AI suggested using requestAnimationFrame to try and predict a good time to release the latch, but this has a flaw in certain contexts as discovered in fix: CI tests on OS X blockly-keyboard-experimentation#770. It's not guaranteed when (or if in some cases) the callback for requestAnimationFrame will be called.
• AI suggested using setTimeout in conjunction with requestAnimationFrame to try and guard against all scenarios. This might work, but it will be challenging to get everything properly wired.

Both approaches are non-trivial and will require a lot of multi-browser and multi-screenreader testing to feel good about them.

Actually based on the above message I am going to close this and update #9122 accordingly.